Financial transfers from mobile devices

ABSTRACT

Computer-implemented systems, methods, and computer-readable media for financial transfers from a mobile device, comprising: receiving a mobile device identifier, a unique user identifier, a merchant identifier, and an amount from a mobile device; determining whether the transaction is authorized based on the mobile device identifier and the unique user identifier; transmitting an authorization failure message to at least one of the mobile device and a merchant device associated with the merchant identifier if it is determined that the transaction is not authorized; and transmitting to a payment gateway an account identifier associated with the unique user identifier and mobile device identifier, the merchant identifier, and the amount if it is determined that the transaction is authorized.

RELATED APPLICATION DATA

This application claims priority to Indian Patent Application No.4607/CHE/2011, filed Dec. 27, 2011, and Indian Patent Application No.4608/CHE/2011, filed Dec. 27, 2011, both of which are herebyincorporated by reference in its entirety.

BACKGROUND

Credit cards allow users to carry less liquid currency. However, despitethe security mechanisms implemented in relation to credit cardtransactions, credit card users continue to place themselves at risk. Ifa credit card is stolen, the thief can very quickly charge up to thecredit limit before the card owner even realizes that the credit card ismissing. Additionally, because most credit card authorizations onlyrequire information that is plainly visible on the card (e.g., theaccount number, owner name, expiration date, and Card Security Code(“CSC”)), a duplicitous cashier or call center worker may copy down thecredit card authorization information to make unauthorized transactionswithout even stealing the physical card. More recently, some cards haveincorporated Radio Frequency Identification (“RFID”) and similarshort-range wireless communication systems to allow for more convenient“touchless” credit card transactions. However, such wireless creditcards have reduced security even further by allowing for hands-freetheft by homemade scanning devices.

To both increase security and convenience, many companies have beenworking to develop mobile device (e.g., mobile phone) based paymentsystems as substitutes for conventional credit cards. While such paymentsystems alleviate some security concerns presented by credit cards, theyalso perpetuate others. For example, mobile device based payment systemsgenerally include personal information and account information on thedevice itself, so if a thief steals the device they may gain access tothe device owner's account information. Additionally, known mobiledevice payment systems usually include a close-range wireless connectionbetween the mobile device and a Point-of-Sale (“POS”) device (e.g., viaNear Field Communication (“NFC”)) for the mobile device to transmitpayment information. Such transmissions may still enable sophisticatedthieves to intercept account information.

Still other systems attempt to increase security by allowing for a userto provide their account information to a merchant then requiringindependent authorization by the user via their mobile device before thepayment can be authorized. In such a system, the merchant's POS devicemay submit a request for authorization of a charge, the submissionincluding the user's account information. A back-end payment system maythen send a message (e.g., a Short Message Service (“SMS”) message) tothe user's mobile device requesting authorization of the charge. Theuser may then authorize the completion of the transaction by eitherproviding a code to the merchant (e.g., a code received via an SMSmessage) or may respond to the message and the back-end system maytransmit authorization to the merchant. However, in similar fashion toconventional credit cards and mobile device payment systems using NFC,these systems still require sensitive data relating to a user's accountto be transmitted between a user and a merchant or between a user'sdevice and a merchant's device.

Improved mobile financial transfer systems are desired.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary architecture for making financial transfersfrom a mobile device.

FIG. 2 shows a process flow for a mobile payment system to receive arequest for a financial transfer from a mobile device, determine whetherthe transfer is authorized, and, if the transfer is authorized, providethe appropriate information to a payment gateway.

FIG. 3 shows an exemplary data flow illustrating that the mobile paymentsystem may be deployed within existing payment gateway architectureswithout modification.

FIG. 4 shows an exemplary architecture for making financial transfersfrom a mobile device where the mobile device receives data from thepoint of sale device.

FIG. 5 shows an exemplary computing device useful for performingprocesses disclosed herein.

While systems and methods are described herein by way of example andembodiments, those skilled in the art recognize that systems and methodsfor financial transfers from mobile devices are not limited to theembodiments or drawings described. The drawings and description are notintended to be limiting to the particular form disclosed. Rather, theintention is to cover all modifications, equivalents, and alternativesfalling within the spirit and scope of the appended claims. Any headingsused herein are for organizational purposes only and are not meant tolimit the scope of the description or the claims. As used herein, theword “may” is used in a permissive sense (i.e., meaning having thepotential to) rather than the mandatory sense (i.e., meaning must).Similarly, the words “include,” “including,” and “includes” meanincluding, but not limited to.

DETAILED DESCRIPTION

Disclosed embodiments provide systems, computer-implemented methods, andcomputer-readable media for performing financial transfers with mobiledevices, such as smartphones (e.g., phones using the iOS, Android, orBlackBerry OS operating systems) and tablets. In contrast to the manysolutions being developed to allow a person to initiate a financialtransfer by having their mobile device operatively couple with a POSdevice as described in the background, embodiments may allow a user toinitiate a secure financial transfer using their mobile device withoutcommunicating any account information directly to the merchant. Thus,embodiments may transfer absolutely no account information from a mobiledevice to a POS device that a duplicitous employee could steal.

Additionally, the systems disclosed in the background each include theirown infrastructure which may be expensive to deploy. For example, moderncredit card systems generally require scanning devices associated withPOS devices that communicate with a payment gateway or front-end creditcard processing system via a network connection to determine whether acharge is authorized (i.e., whether both the account is valid andwhether the amount is authorized). Currently suggested mobile devicepayment systems require installation of expensive new equipment at POSdevices and new back-end infrastructures. In contrast to theseexpensive-to-deploy systems, embodiments may utilize existing paymentgateways. Thus, embodiments may be less expensive to deploy than currentmobile device payment systems because they do not require new hardwareto be integrated with POS devices or new back-end infrastructures.

FIG. 1 shows an exemplary architecture 100 for making financialtransfers from a mobile device. In a typical POS transaction, a payer115 purchases goods or services from a merchant 130. Rather than payingwith cash or a credit card, embodiments may allow payer 115 to utilizean application on their mobile device 105 to pay the merchant. At thePOS, the merchant 130 may provide the payer with a unique MerchantIdentification Number (“MIDN”). The MIDN may be a unique identifieruseful for a payment gateway 125 (discussed further below) to identifythe merchant's account. The merchant 130 may also provide payer 115 witha total amount for a purchase of goods or services.

Next, payer 115 may enter the MIDN identifying who will receive thefinancial transfer, the amount of the financial transfer, and a uniqueuser identifier (“UUI”) into a user interface (“UI”) of the mobiledevice. Embodiments may also allow the payer 115 to enter additionalinformation, for example a memo line may allow the payer 115 to includea note relating to the transaction for their own record keeping. The UUImay be a Personal Identification Number (“PIN”), an alpha-numericpassword, or an answer to a payer-specific question. In someembodiments, the UUI may be any other user input, such as a pattern ordrawing traced on a touch-screen display. In some embodiments, the UUImay be a biometric input (e.g., a voice-recognized word or phrase, adetected fingerprint, a detected iris pattern, a detected face, etc.).Biometric input may be detected via conventional mobile device inputdevices (e.g., microphones, cameras, touch-displays, etc.) or may beinput by special purpose devices integrated into or coupled to themobile device (e.g., finger print readers). Embodiments may beconfigured to utilize one or more of these or other UUIs according tospecific security needs and device capabilities.

The mobile device 105 may then transmit the UUI, MIDN, and amount, aswell as a mobile device identifier (“MDI”) to a back-end mobile paymentsystem 120. The MDI may be a hardware specific identifier, such as anInternational Mobile Equipment Identity (“IMEI”) number. Such anidentifier may identify the exact mobile device making the transmission.Alternatively, the mobile device identifier may be a phone number oridentifier assigned to the mobile device by a mobile carrier.

While FIG. 1 shows the transmission directly from mobile device 105 tomobile payment system 120, the transmission may pass through one or moreintermediaries. For example, the transmission may be via an applicationor web app running on mobile device 105 and the connection may be madeto a destination Uniform Resource Locator (“URL”), Internet Protocol(“IP”) address, or any other address. In such embodiments, the mobiledevice 105 may transmit via a mobile carrier's network (e.g., a 4Gnetwork) and the mobile carrier may then route the transmission to themobile payment system 120 via one or more other networks, such as theinternet.

Once the mobile payment system 120 receives the MIDN, UUI, MDI, andtransfer amount, the mobile payment system may perform the process flowshown in FIG. 2. FIG. 2 shows a process flow 200 for a mobile paymentsystem 120 to receive a request for a financial transfer from a mobiledevice, determine whether the transfer is authorized, and, if thetransfer is authorized, provide the appropriate information to a paymentgateway. As shown in process flow 200, at step 205 the payment systemmay receive the MIDN, at step 210 the payment system may receive the UUIand MDI, and at step 215 the payment system may receive the transferamount. Steps 205, 210, and 215 may occur in any order orsimultaneously. In each of these steps the received information may beencrypted, for example using a private key or certificate. If thereceived information is encrypted, the system may also decrypt allreceived information.

Next, at step 220 the system may determine whether the UUI and MDIcorrespond to an authorized account. For example, a dataset ofauthorized accounts may store for each account one or more UUIs ofauthorized users and one or more MDIs of authorized mobile devices. Insuch embodiments, the system may perform a search of all accounts todetermine whether an authorized account corresponds to both the receivedUUI and the received MDI. At step 225, if it is determined that thereceived identification information corresponds to an authorizedaccount, the system may transmit account information associated with theUUI and MDI, the MIDN, and the transfer amount to a payment gatewayassociated with the authorized account in step 230 (e.g., paymentgateway 125 shown in FIG. 1). The account information, MIDN, andtransfer amount may be transferred to a payment gateway in aconventional format, for example using the format currently utilized forcredit cards or debit cards. Alternatively, if it is determined that therequest is not valid, an authorization failure message may betransmitted back to the attempting payer's device or any other device orsystem in step 235.

By way of example, a UUI password “password” and an MDI “12345” may beregistered with an account associated with a credit card having a name“John Doe”, a number “1234 5678 9101 1213”, an expiration date “01/13”,and a CSC “123”. If in step 210 the system received the UUI “password”and an MDI “12345”, at step 220 the system may determine that therequest is an authorized request for a financial transfer from JohnDoe's account and at step 230 the system may transmit a request to apayment gateway including account information such as John Doe's name,credit card number, credit card expiration date, and CSC as well as thetransfer amount and the MIDN. Because existing payment gateways areconfigured to receive these data, embodiments may be deployed withinexisting system architectures without requiring any modification tocredit card payment gateways or merchant POS devices.

After the system transmits the MIDN, account information, and transferamount to a payment gateway in step 230, the system may optionally beconfigured to receive a confirmation or denial from the payment gateway.The system may then be configured to transmit the confirmation or denialto the payer's mobile device in step 245.

While the above example references a credit card account, embodimentsmay be configured to work with any account architecture. For example, ifbeing utilized within a debit card account system, the system may have aPersonal Identification Number (“PIN”) associated with an account andmay transmit the PIN to the payment gateway along with all othernecessary information to make the transfer. Still other embodiments maybe configured to utilize less conventional systems, such as systems forredeeming accrued bonus points (e.g., airline points on an airlinecredit card), systems for making PayPal purchases, and the like.

Referring again to FIG. 1, if authorized by the mobile payment system120, the transfer request (including all necessary account information,the transfer amount, and the MIDN) may be transmitted to the paymentgateway 125. While payment gateway 125 is illustrated as a single entityin FIG. 1 and described above in the context of a credit card paymentprocessor, the payment gateway may be any system that facilitates thetransfer of information between the mobile payment system 120 and thefront-end processor of a credit card provider, a bank, or any otherinstitution that can authorize the payment. In some embodiments,existing systems, such as Sybase 365 systems, may be utilized as thepayment gateway 125.

If the payment gateway authorizes or receives authorization of thepayment, the payment gateway may transmit the payment authorization tothe point of sale device 110. The MIDN may include sufficientinformation for the payment gateway to contact the POS device (e.g., aURL, IP address, phone number, etc.). The merchant 130 may then observethe confirmed payment and provide the purchased goods or services to thepayer 115.

As FIGS. 1 and 2 show, embodiments allow for a payer 115 to transferfinances to merchant 130 without disclosing any potentially sensitiveinformation to the merchant. While the payer 115 may provide a generalidentifier, such as the payer's name, to the merchant so that thepayment authorization may be matched to the specific payer 115,embodiments alleviate the need to provide any account relatedinformation (e.g., account numbers, credit card numbers, PINs, etc.)that could be stolen to make fraudulent purchases. This provides abenefit over system that utilize NFC or similar technologies to pass“secure” data between a mobile device and a POS device because even such“secure” data may be intercepted and potentially used to provideunauthorized access to payer 115's account.

These figures also show that the mobile device does not require accessto any account information at all. Rather, the mobile device onlyrequires an application to be installed or run from a web browser. Eventhis application does not need to know any of the payer's accountinformation; it simply detects the MDI and allows a user to enter theirUUI. The mobile payment system securely maintains associations betweenaccounts and one or more corresponding MDI and UUI. Thus, even if themobile device is lost or stolen, it has no account information thatcould be extracted to make fraudulent payments.

FIG. 3 shows an exemplary data flow 300 illustrating that the mobilepayment system may be deployed within existing payment gatewayarchitectures without modification. Additionally, data flow 300illustrates that the information transmitted from the mobile device maycontain no user account information. First, mobile device 305 mayreceive a request for a transaction from a user. For example, a user mayenter a merchant ID, a transaction amount, and a secure identifier(e.g., password) into an application's or web app's UI. Mobile device305 may then transmit all data required to authorize the transfer inmobile payment system 315 across a mobile network to a mobile carriersystem 310. This information may include both the information input bythe user and a device identifier. This information does not need toinclude any account information. The mobile carrier system 310 may thenpass the data on without modification to the mobile payment system 315,for example by routing the data from the mobile network to anothernetwork (e.g., the internet).

Mobile payment system 315 may receive and process the data to determinewhether the secure identifier and the device identifier correspond to anauthorized account. If they correspond to an authorized account, theaccount may include data indicating a payment gateway for the user aswell as account details for the user. Mobile payment system 315 may thentransmit to the payment gateway 320 all data required to authorize thetransaction, such as a credit card's user name, number, expiration date,and CSC, an amount of the transfer, and an identification of themerchant account to receive the transfer. The payment gateway 320 mayreceive the data transmitted from the mobile payment system 315 andprocess it in conventional fashion. If the payment is authorized, thepayment gateway 320 may transmit a notification of the authorization andany relevant information (e.g., the authorized user, the amount, thedate the transaction will settle, etc.) to the POS device 325.Alternatively, if the transaction is not authorized (e.g., the accountis overdrawn or has been closed), the payment gateway 320 may transmit anotification of the denial to the POS device 325. While not shown, thepayment gateway 320 may also transmit a notification of authorization ordenial back to the mobile payment system 315 which may, in turn,ultimately transmit a notification back to the mobile device 305. Oncethe POS device 325 receives a notification that the payment isauthorized, a merchant may give the user the goods or services they arepurchasing.

As shown in FIG. 3, a user may avail embodiments across the globe andindependent of the telecom service provider providing mobile networkaccess. Because embodiments only require network connectivity (e.g., viawired or wireless networks), embodiments may be completely carrierindependent. Alternatively, some embodiments may require all paymentrequests to be received from a specific mobile carrier to provide anadditional level of security at the expense of cross-platformconvenience.

While in the above discussed embodiments a user may input all necessarydata into their mobile device, in alternative embodiments some necessarydata may be received by the mobile device in alternative fashions. FIG.4 shows an exemplary architecture 400 for making financial transfersfrom a mobile device where the mobile device receives data from thepoint of sale device. In such an embodiment, mobile device 105 mayreceive at least one of the amount of the transaction and the merchant'sidentification automatically. For example, a camera on a mobile devicemay be utilized optically recognize at least one of the MIDN and theamount of the transfer from a barcode, Quick Response (“QR”) code,screen readout, and the like. Alternatively, a wireless communicationcoupling (e.g., via NFC) may be utilized to transmit at least one of theMIDN and the amount from the POS device to the mobile device. However,even though information relating to the transaction may be transmittedfrom the POS device 110 to the mobile device 105, this embodiment maystill avoid transmitting any account related information from the mobiledevice 105 to the POS device 110. The remaining architecture 400 mayprocess a financial transaction in similar fashion to architecture 100described in reference to FIG. 1 above.

While the above embodiments generally describe financial transfersoccurring at POS devices, embodiments may be implemented to allow forother secure financial transactions to be initiated from a mobiledevice. For example, embodiments may be utilized for a user to makeon-line purchases. In such embodiments, an ecommerce website may provideand MIDN and total amount of a purchase at checkout. The customer (i.e.,a user) may then initiate the financial transfer on their mobile deviceby entering in the MIDN, total, and their UUI into an appropriateapplication. Alternatively, at least one of the MIDN and total may beautomatically received by the mobile device from the ecommerce website(e.g., if the website were accessed via a browser on the mobile device).In such on-line purchase embodiments, a user may purchase from anyecommerce website without disclosing any account information to thewebsite. Such embodiments may prevent an ecommerce website worker fromstealing account information to make fraudulent purchases. Suchembodiments may also be configured to avoid phishing scams by having thepayment gateway validate all MIDNs.

Embodiments may also be configured to allow a user to transfer money toanother user. For example, individual users may register accounts with apayment gateway and receive a MIDN in similar fashion to how a merchantwould. The receiving user (i.e., payee) may then tell the paying user(i.e., payer) their MIDN and the paying user may enter the amount, thereceiving user's MIDN, and their UUI into an application to initiate thetransfer in similar fashion to the above description of FIG. 1. In otherembodiments, the users' phones may operatively couple to allow thepayee's phone to transmit the payee's MIDN to the payer's phone (e.g.,the phones may “bump” using NFC). In such embodiments, a payer's phonemay transmit no account information to the payee's phone.

Embodiments may be configured to accept voice commands for performingall transactions. Such embodiments may be configured to recognize thevoice of only a specific authorized user. Such embodiments may be usefulto both biometrically authenticate an authorized user and to allow forhands-free use of the mobile device.

Embodiments may also be configured to store receipts or othertransaction related data. For example, a mobile device may be configuredto receive a receipt from a POS device, for example over NFC. The mobiledevice may store a local copy of the receipt for later review, mayupload the receipt to cloud storage, may upload the receipt to themobile payment system (which itself may be in the cloud), or mayotherwise process the receipts or other transaction data. In someembodiments, the mobile device may store received receipts locally untilthe device receives network connectivity and then transfer the receiptsto cloud storage.

In addition to allowing the user to pay the amount indicated by amerchant, embodiments may allow a user to enter a tip amount. Forexample, embodiments may include a tip calculator in an application toallow the user to enter a tip by tip amount, by tip percentage, or byquality of service (e.g., the calculator may add 0% for awful service,5% for poor service, 15% for good service, and 25% for exceptionalservice).

Embodiments may also be configured to provide ads or promotions to auser interface. For example, embodiments may provide a user withdirected promotions based on previous purchases or other financialtransfers. Thus, embodiments may conveniently help a user to find thebest deals based on their individual habits. Embodiments may allow theuser to redeem promotions directly from their mobile device, for exampleby selecting a promotion and providing their UUI to authorize thepurchase of the promoted goods or services.

Embodiments may also provide account management tools. For example,embodiments may provide tools to allow a user to close an account, viewa transaction history, cancel a credit card payment (e.g., because apurchased product is defective), view an account balance, and the like.Embodiments may also allow for a bank or financial institution to pushinformation to a user via their mobile device, for example messagesabout the user's account (e.g., e-statements), notifications of feechanges, promotions, and the like.

The embodiments described herein may be implemented with an applicationrun on a mobile device. The application may, for example, be downloadedfrom a bank's website. The downloaded application may be configured toknow the authorized payment gateway for the account. When theapplication is installed, it may automatically retrieve the IMEI andother details of the phone on which it is installed. A user may thensimply register their UUI with the bank to complete initialauthorization of the mobile financial transfer system.

Other embodiments may utilize web apps (i.e., applications executedthrough an internet connected browser). Such embodiments may provide auser with convenient access to their account without requiringinstallation of an application on their mobile device. In suchembodiments, the user may register their mobile device's IMEI with theirbank. Then, when the web app is used to make a financial transfer, theuser may enter their UUI and the web app may automatically detect themobile devices IMEI to authenticate the transfer.

In still other embodiments, the application may be made an integral partof the operating system image installed on the mobile device. Suchembodiments may provide additional security since the application cannotbe easily uninstalled or tampered with.

Further, embodiments may be used in conjunction with conventionalpayments systems. For example, a bank may issue a credit card andauthorize a mobile financial transfer account for the same user. In suchembodiments a user may chose to use their credit card if they do nothave their phone with them or may use their mobile phone to initiate atransaction if they do not have their credit card with them or if theywish to perform the transaction with additional security. In suchembodiments, an application useful for performing the secure mobilefinancial transaction may also be useful for managing transactions madewith the credit card. Such embodiments may also utilize other knownmobile financial service systems, such as Google Wallet, on the samemobile device.

The above embodiments generally describe the MDI being a mobile phone'sIMEI. In alternative embodiments, the MDI may be data stored on aSubscriber Identification Module (“SIM”) card provided by a mobilecarrier. In still other embodiments, the MDI may be provided by a softSIM image, such as the soft SIM image describe in the patent applicationfiled concurrently herewith titled “METHOD AND APPARATUS FOR REGISTERINGA COMPUTING DEVICE WITH A SERVICE PROVIDER” invented by Anoop Narayananhaving docket number IN-PED-0918, the entire contents of which areincorporated herein by reference. The SIM image may be a read-only,encrypted copy of a physical SIM card. Such embodiments may incorporatean application or operating system level driver in the mobile device forreading the soft SIM. The subscriber may register the IMEI number of hisor her mobile device with the service provider and the soft SIM, like aplastic SIM card, may have a unique cell number to identify the GlobalSystem for Mobile Communications (“GSM”) subscriber. Embodiments usingan MDI associated with a SIM card or soft SIM may conveniently allow auser to maintain the same MDI associated with an account after theyupgrade their mobile device.

Thus, a soft SIM may provide a digital signature to securely anduniquely identify an authorized mobile device and user. A single softSIM may act as a digital signature for all transactions performed fromthe device in conjunction with a unique device identifier, such as anIMEI number or other data embedded in read-only memory which uniquelyidentifies the device. In other words, a device registered with aservice provider may act as a digital signature of a person. Financialtransactions (e.g., transfers) may be required to be performed from thesignature device (i.e., the device having the soft SIM) and may requirea dynamically changing authentication (e.g., a PIN or password). Asingle device may have plural soft SIMs but the same soft SIM may not beused on more than one device.

While the above embodiments generally describe financial transfers froma user to another user or to a merchant, embodiments may also be usefulfor allowing a user to securely withdraw money from an ATM using theirmobile device. Such embodiments may add a level of security toconventional ATM withdrawals. In such embodiments, a user may utilize anapplication on their mobile device and enter a unique identifier for thebank in the MIDN field, the amount of the withdrawal, and their UUI. Theapplication may then give the user a temporary PIN number valid for aspecific time interval and for the specific cash amount. The user canthen visit the ATM of that respective bank, enter the PIN number, andwithdraw the cash within the allowed time limit. In other embodiments,the PIN may be valid for a specific time interval but the cash amountmay not be predetermined.

These embodiments may be implemented with software, for example modulesexecuted on computing devices such as computing device 510 of FIG. 5. Ofcourse, modules described herein illustrate various functionalities anddo not limit the structure of any embodiments. Rather the functionalityof various modules may be divided differently and performed by more orfewer modules according to various design considerations.

Computing device 510 has one or more processing device 511 designed toprocess instructions, for example computer-readable instructions (i.e.,code) stored on a storage device 513. By processing instructions,processing device 511 may perform the steps and functions disclosedherein. Storage device 513 may be any type of storage device (e.g., anoptical storage device, a magnetic storage device, a solid state storagedevice, etc.), for example a non-transitory storage device.Alternatively, instructions may be stored in one or more remote storagedevices, for example storage devices accessed over a network or theinternet. Computing device 510 additionally may have memory 512, aninput controller 516, and an output controller 515. A bus 514 mayoperatively couple components of computing device 510, includingprocessor 511, memory 512, storage device 513, input controller 516,output controller 515, and any other devices (e.g., network controllers,sound controllers, etc.). Output controller 515 may be operativelycoupled (e.g., via a wired or wireless connection) to a display device520 (e.g., a monitor, television, mobile device screen, touch-display,etc.) in such a fashion that output controller 515 can transform thedisplay on display device 520 (e.g., in response to modules executed).Input controller 516 may be operatively coupled (e.g., via a wired orwireless connection) to input device 530 (e.g., mouse, keyboard,touch-pad, scroll-ball, touch-display, etc.) in such a fashion thatinput can be received from a user.

Of course, FIG. 5 illustrates computing device 510, display device 520,and input device 530 as separate devices for ease of identificationonly. Computing device 510, display device 520, and input device 530 maybe separate devices (e.g., a personal computer connected by wires to amonitor and mouse), may be integrated in a single device (e.g., a mobiledevice with a touch-display, such as a smartphone or a tablet), or anycombination of devices (e.g., a computing device operatively coupled toa touch-screen display device, a plurality of computing devices attachedto a single display device and input device, etc.). Computing device 510may be one or more servers, for example a farm of networked servers, aclustered server environment, or a cloud network of computing devices.

The above embodiments may utilize MIDNs corresponding to the entityreceiving the payment initiated from a mobile device. While each MIDNmay be associated with a payee, the MIDN may also be transactionspecific. For example, if an MIDN is a determined number of digits, aportion of the MIDN may be configured to identify the payee and aportion of the MIDN may be configured to identify the specifictransaction. In this fashion, the payee may determine whether thespecific transaction is authorized through the mobile financial transfersystem.

Embodiments have been disclosed herein. However, various modificationscan be made without departing from the scope of the embodiments asdefined by the appended claims and legal equivalents.

What is claimed is:
 1. A computer-implemented method executed by one ormore computing devices for financial transfers from a mobile device, themethod comprising: receiving, by at least one of the one or morecomputing devices, a mobile device identifier, a unique user identifier,a merchant identifier, and an amount from a mobile device; determining,by at least one of the one or more computing devices, whether thetransaction is authorized based on the mobile device identifier and theunique user identifier; transmitting, by at least one of the one or morecomputing devices, an authorization failure message to at least one ofthe mobile device and a merchant device associated with the merchantidentifier if it is determined that the transaction is not authorized;and transmitting, by at least one of the one or more computing devices,to a payment gateway an account identifier associated with the uniqueuser identifier and mobile device identifier, the merchant identifier,and the amount if it is determined that the transaction is authorized.2. The method of claim 1, wherein the mobile device identifier is anInternational Mobile Equipment Identity number; wherein the unique useridentifier is at least one of a Personal Identification Number, apassword, and a biometric identifier; and wherein the determining stepdetermines whether the unique user identifier and the mobile deviceidentifier correspond to an account identifier in an account dataset. 3.The method of claim 1, wherein the step of transmitting to the paymentgateway transmits all data in a format accepted by conventional creditcard payment gateways.
 4. The method of claim 1, wherein the merchantidentifier incorporates a merchant account identification and a uniquetransaction identification.
 5. The method of claim 1, wherein the mobiledevice identifier, unique user identifier, merchant identifier, andamount are received from a mobile device via a wireless data connection.6. The method of claim 1, wherein the mobile device identifier, uniqueuser identifier, merchant identifier, and amount are received from amobile device via an encrypted Short Message Service message.
 7. Themethod of claim 1, wherein the mobile device identifier is a softSubscriber Identification Module.
 8. A system for financial transfersfrom a mobile device comprising: a memory; and a processor operativelycoupled to the memory, the processor configured to perform the steps of:receiving a mobile device identifier, a unique user identifier, amerchant identifier, and an amount from a mobile device; determiningwhether the transaction is authorized based on the mobile deviceidentifier and the unique user identifier; transmitting an authorizationfailure message to at least one of the mobile device and a merchantdevice associated with the merchant identifier if it is determined thatthe transaction is not authorized; and transmitting to a payment gatewayan account identifier associated with the unique user identifier andmobile device identifier, the merchant identifier, and the amount if itis determined that the transaction is authorized.
 9. The system of claim8, wherein the mobile device identifier is an International MobileEquipment Identity number; wherein the unique user identifier is atleast one of a Personal Identification Number, a password, and abiometric identifier; and wherein the determining step determineswhether the unique user identifier and the mobile device identifiercorrespond to an account identifier in an account dataset.
 10. Thesystem of claim 8, wherein the step of transmitting to the paymentgateway transmits all data in a format accepted by conventional creditcard payment gateways.
 11. The system of claim 8, wherein the merchantidentifier incorporates a merchant account identification and a uniquetransaction identification.
 12. The system of claim 8, wherein themobile device identifier, unique user identifier, merchant identifier,and amount are received from a mobile device via one of a wireless dataconnection and an encrypted Short Message Service message.
 13. Thesystem of claim 8, wherein the mobile device identifier is a softSubscriber Identification Module.
 14. A non-transitory computer-readablemedium having computer-readable code stored thereon that, when executedby a computing device, performs a method for financial transfers from amobile device, the method comprising: receiving a mobile deviceidentifier, a unique user identifier, a merchant identifier, and anamount from a mobile device; determining whether the transaction isauthorized based on the mobile device identifier and the unique useridentifier; transmitting an authorization failure message to at leastone of the mobile device and a merchant device associated with themerchant identifier if it is determined that the transaction is notauthorized; and transmitting to a payment gateway an account identifierassociated with the unique user identifier and mobile device identifier,the merchant identifier, and the amount if it is determined that thetransaction is authorized.
 15. The medium of claim 14, wherein themobile device identifier is an International Mobile Equipment Identitynumber; wherein the unique user identifier is at least one of a PersonalIdentification Number, a password, and a biometric identifier; andwherein the determining step determines whether the unique useridentifier and the mobile device identifier correspond to an accountidentifier in an account dataset.
 16. The medium of claim 14, whereinthe step of transmitting to the payment gateway transmits all data in aformat accepted by conventional credit card payment gateways.
 17. Themedium of claim 14, wherein the merchant identifier incorporates amerchant account identification and a unique transaction identification.18. The medium of claim 14, wherein the mobile device identifier, uniqueuser identifier, merchant identifier, and amount are received from amobile device via one of a wireless data connection and an encryptedShort Message Service message.
 19. The medium of claim 14, wherein themobile device identifier is a soft Subscriber Identification Module.